home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Columbia Kermit
/
kermit.zip
/
newsgroups
/
misc.19971216-19980424
/
000071_news@newsmaster….columbia.edu _Thu Jan 8 16:53:06 1998.msg
< prev
next >
Wrap
Internet Message Format
|
2020-01-01
|
3KB
Return-Path: <news@newsmaster.cc.columbia.edu>
Received: from newsmaster.cc.columbia.edu (newsmaster.cc.columbia.edu [128.59.35.30])
by watsun.cc.columbia.edu (8.8.5/8.8.5) with ESMTP id QAA12288
for <kermit.misc@watsun.cc.columbia.edu>; Thu, 8 Jan 1998 16:53:05 -0500 (EST)
Received: (from news@localhost)
by newsmaster.cc.columbia.edu (8.8.5/8.8.5) id QAA03040
for kermit.misc@watsun; Thu, 8 Jan 1998 16:53:05 -0500 (EST)
Newsgroups: comp.protocols.kermit.misc
Path: news.columbia.edu!panix!howland.erols.net!ix.netcom.com!gerlach
From: gerlach@netcom.com (Matthew H. Gerlach)
Subject: Re: Kermit vs SCO pttys
Message-ID: <gerlachEMHJ12.D4B@netcom.com>
Organization: Netcom Online Communications Services (408-241-9760 login: guest)
References: <69339l$1ksa$1@newssvr03-int.news.prodigy.com>
Date: Thu, 8 Jan 1998 21:43:49 GMT
Lines: 41
Sender: gerlach@netcom18.netcom.com
Xref: news.columbia.edu comp.protocols.kermit.misc:8241
I'm not sure how relevent my experience is, but here goes. I have used
Expect and a Perl functional equivelent to "talk" to kermit running
on SCO 3.2.4. Both Expect and Perl's functional equivent use ptys for this
"talking". In the process of doing this, I've noticed a few important
items. First and formost, shuting down kermit gracefully really helps.
Secondly, a very common problem is that if you don't gracefully shutdown
kermit, but "kill" it, you must be sure to reap the dead with a call
to the wait() function. If you don't there will be zombies floating around,
and you could run out of ptys and processes. However, when your parent
progam exits, UNIX will do the reaping for you; so a post mortem won't tell
you of the problem.
Matthew H. Gerlach
In article <69339l$1ksa$1@newssvr03-int.news.prodigy.com> GXXE75A@prodigy.com (Morgan Johnson) writes:
>I am using C-Kermit to control unattended data transfers from several
>remote Unix systems and one central Unix system. All systems are SCO 3.2.
>4.2. I am using Kermit since some systems are on a network and some
>require dialup, and Kermit gives me a consistent interface.
>
>On the networked machines, the remote system assigns a ptty to handle the
>kermit connection. For some reason, these pttys are not being released
>for re-use. E.G.: one of the systems was rebooted at the end of 1/6.
>Since then there have been six connections made using C-Kermit, and at
>this time ttyp0-5 are no longer available. When I telnet in, or use
>Kermit, the system assigns me ttyp6. It does this consistently, and does
>NOT advance the ptty number, which is to say, I cannot recreate the
>problem. I have tried breaking the connection in various nasty ways, I
>have checked for lingering processes, I have reviewed the streams
>resources, etc., checked the ownership and permissions on the pttys, etc.,
> etc. Normal telnet connections never cause the problem, but every Kermit
>connection made at night does cause it.
>
>Any ideas?
>
>Morgan Johnson, GXXE75A@prodigy.com
>